Somewhat unrelated to this PR - I think defining the order-independence of the hash at the type level is the wrong way to go about this. Nothing is preventing the rest of the compiler from relying on the option order.

Instead, I think DepTrackingHash shouldn't do any re-ordering at all. Order-independence can be implemented by having the option parsing code sort the parsed Vec immediately after it gets parsed. That makes it impossible for any compiler code to accidentally rely on the original command-line argument order.

So I'm looking back over this - I think the only way this could change a hash is that Option<Vec<String>> will no longer be sorted before being hashed. That's looks like it's only used for allow_features, which shouldn't need to depend on the order:

$ rg ': Option<Vec<String.*\[TRACKED' compiler/rustc_session/src/options.rs
895:    allow_features: Option<Vec<String>> = (None, parse_opt_comma_list, [TRACKED],

Having Option<Vec> be unsorted but Vec be sorted seems really fishy to me, I think changing this is ok.

Instead, I think DepTrackingHash shouldn't do any re-ordering at all. Order-independence can be implemented by having the option parsing code sort the parsed Vec immediately after it gets parsed. That makes it impossible for any compiler code to accidentally rely on the original command-line argument order.

That makes sense to me. I see the following Vecs used:

$ rg ': .*Vec<.*\[TRACKED' compiler/rustc_session/src/options.rs
86:        crate_types: Vec<CrateType> [TRACKED],
92:        lint_opts: Vec<(String, lint::Level)> [TRACKED],
97:        libs: Vec<(String, Option<String>, NativeLibKind)> [TRACKED],
829:    llvm_args: Vec<String> = (Vec::new(), parse_list, [TRACKED],
833:    metadata: Vec<String> = (Vec::new(), parse_list, [TRACKED],
851:    passes: Vec<String> = (Vec::new(), parse_list, [TRACKED],
895:    allow_features: Option<Vec<String>> = (None, parse_opt_comma_list, [TRACKED],
920:    crate_attr: Vec<String> = (Vec::new(), parse_string_push, [TRACKED],

Are llvm's arguments order-sensitive? Or passes? The others look like they should be order insensitive.

Ok, I take it back, I see the following order-dependent uses:

compiler/rustc_save_analysis/src/lib.rs
97:        let crate_type = sess.crate_types()[0];

and indirectly through dependency_formats (which depends on the order of crate_types):

compiler/rustc_codegen_ssa/src/back/linker.rs
1253:    let formats = tcx.dependency_formats(LOCAL_CRATE);
1254-    let deps = formats.iter().find_map(|(t, list)| (*t == crate_type).then_some(list)).unwrap();

There might be more, I only looked at crate_types.

Should I just sort all these and hope nothing breaks?

Should I just sort all these and hope nothing breaks?

The line in rustc_save_analysis seems questionable - I don't think we have a notion of 'primary/main crate type' anywhere else.

I'm not sure about dependency_formats - I'd recommend asking someone more familiar with that code. For now, I think it would be fine to leave that unsorted, and investigate further if anyone complains about the performance impact of switching around --crate-type flags during incremental compilation.

I won't have time to follow up on this in the next month or so. Do you think this is ok to land as-is or do you want the broader change with sorting first?

Ok, this is a nice small PR now.

@bors r+

📌 Commit 76502de has been approved by Aaron1011

⌛ Testing commit 76502de with merge 9e6f0e8...

☀️ Test successful - checks-actions
Approved by: Aaron1011
Pushing 9e6f0e8 to master...